tele9752wikiaorg-20200213-history
UPNP
Universal Plug and Play (UPnP) UPnP, which is the acronym for Universal Plug and Play, is a set of protocols that defines a networking architecture that are open and distributed. The UPnP architecture invokes existing TCP/IP and Internet based technologies such as UDP, HTTP, XML and SOAP. By enabling UPnP on the devices, two or more devices can seamlessly communicate with each other, sharing data and access to the services the devices provide via any control device over the network. The UPnP architecture primarily targets internal networks, such as home network and small business network. Currently the UPnP standards are maintained by UPnP Forum, which is formed in 1999. The main feature of UPnP is that it requires zero configuration of the device that joins the network. This Wiki page contains concise information about UPnP architecture, the configuration and security issues, and its application in general. Acronym Building Blocks The UPnP architecture consists of the following three building blocks: *Devices *Services *Control Points Their relationship can be shown with figure 1. Device Here the device means logical device. Which can be thought as a collections of one or more related services and put them into a box. The device can embed other devices. The logical devices rely on physical devices and multiple logical devices can be included in one physical devices. Service Service is the smallest unit that can be controlled over UPnP. Services defines device actions and monitors device states. The control point can send an action/control request to the device. While the device executes the action, the associated state variables, which are used to monitor device status, may change as a consequence. When the state variable changes, the service can publish the event and the control point which is subscribed to the service will obtain the notification. Control point A control point discovers devices presented on the network, retrieves their device and service descriptions and control them by sending control packets to the device services. Control point is also a subscriber of the event service of the devices. The control point is a logical controller that can be implemented on both hardware device and software platform. UPnP Protocol Stacks Figure 2 shows the protocol stacks used by the UPnP architecture. The most fundamental protocol stack is the IP stack. The TCP and UDP stacks are used as the transport protocol. As UPnP technology is based on HTTP, the HTTP protocol which is originally designed to operate on TCP is modified to operate on UDP to perform unicast (HTTPU) and multicast (HTTPMU) communication between networked elements. UPnP device architecture An UPnP enabled device architecture consists of the following components: #Addressing #Discovery #Description #Control #Eventing #Presentation 1. Addressing Before the new device or new control point can be added to existing network, it has to be assigned with a unique IP address. This is normally and most easily done by sending request to the DHCP server. However, if the DHCP server is not available, the Automatic Private IP Addressing (APIPA), also known as Auto-IP, will be used to assign IP addresses. Generally, UPnP device addressing prefers to use DHCP rather than Auto-IP. It will regularly check the availability of the DHCP server. If DHCP server becomes available after the device assigns Auto-IP, the device IP address will be reassigned using DHCP. Brief introduction about Auto-IP When the Auto-IP is used, the TCP/IP stack selects a random IP address in the non-routable address range (169.254/16). Since the first and last 256 addresses in this range are reserved, they cannot be used. As a consequence, the non-routable address range is from 169.254.1.0 to 169.254.254.255. The subnet mask uses the default class B subnet mask 255.255.0.0. Once the TCP/IP stack selects an IP address, the device sends out an ARP (Address Resolution Protocol) probe with the selected IP address to the network and see if there is any other devices on the network responds to the probe. If an ARP response is received, this indicates the selected address has been assigned to another device. Then the TCP/IP stack will select an new IP address and another ARP probe will be send out to test the address availability. This process is looping until no ARP response is received. 2. Discovery Once the device is added into the network and obtains a unique IP address, its presence needs to be known by the control point. So that the control point can learn the device capability and its accessible services, and subsequently invoke desired actions to these service. UPnP architecture adopts the SSDP through unicasting and multicasting over the UDP to provide two types of approaches for device discovery: #Advertisement, based on GENA #Search The discovery architecture can be shown in figure 3: Advertisement When a device joins, leaves or changes its states (e.g. device IP address expires, new IP address has just assigned to the device), the device has to send an advertisement over the network to inform other devices about the changes. The advertisement is multicasting to 239.255.255.250:1900, which are the standard multicast address and port the control points listen to. There are three types of advertisements. *ssdp:alive -> device available (format shown in figure 4) *ssdp:byebye -> device unable (format shown in figure 5) *ssdp:update -> device update (format shown in figure 6) In summary, the starting line for SSDP advertisement is NOTIFY * HTTP/1.1\r\n. The Notification Type (NT) and Unique Service Name (USN) have been defined by UPnP Forum and the available choices are listed in the following table. For detailed definition of each NT and USN, please refer to the UPnP Device Architecture Documents: http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v2.0.pdf Search When a new control point is added to the network, instead of advertising, the control point actively searches for the device that provide the service that is interested or desired. For example, if I want to remotely print a document, then the control point in my laptop will send a search query to all the UPnP devices on the network. If there exists a printer that implements the printing service, it will response to the search query and send back basic device information so that the control point can obtain printer’s device and service description for establishing further control. The search requests are sent by using the M-SEARCH method. The multicast message has the format shown in figure 7: Here, the SSDP starting line is M-SEARCH * HTTP/1.1\r\n. The Search Target (ST) can use the same definition as the Notification Type (NT). M-SEARCH method also added an additional ssdp:all ST, which is to search all the devices existed over the network. The M-SEARCH method also support unicast search request. The format of the unicast search is shown in figure 8. Search response Once the device receives search request from the control point, it will compare the ST and USN field in the search request with the NT and USN field in the device advertisement. If the requests matches the device type and service type, the device will send the search response back to the control point address. The format of the search response message is shown in figure 9: Here, the SSDP start line is HTTP/1.1 200 OK. The response is unicast back to the control point. The CACHE-CONTROL ensures that when the device response to a multicast request, it waits for certain amount of time which is defined by max-age. This is to avoid flooding of search response to the control point from multiple devices. 3. Description After device is discovered, the control point only has limited knowledge about the device from the discovery messages. To be able to control the device, the control point has to retrieve its UPnP description. The location of the description is provided as a reachable URL in the LOCATION headerfields. The UPnP description consists of two parts, the device description and service description. These descriptions are written in XML file. The device description describes physical and logical containers. Figure 10 is an example of the device description document tree. The device description The device description also includes the basic information regarding device service. Such as the SCPDURL, controlURL and eventSubURL. The SCPDURL, which is short for service description document URL, is used by the control point to locate the service description document. The controlURL and eventSubURL defines the interface location for the control point to send control request and subscribe to specific event. The service description The service description describes the actions and state variables (state tables) of the devices. It defines the arguments used for the actions. The arguments in the state variable can be used as returned value for the events. An example of service description is shown in figure 11: Retrieving Description Document The description document is retrieved over HTTP with the GET method. The format of the request message is demonstrated in figure 12: The device receives the request and it is expected to respond within 30 second. If it fails to respond in time, the control point will resend the same request. The description document can be sent back in the forms of request response, using CHUNK-LENGTH headerfield. For more information on the details of the format and requirements, please check the UPnP Architecture Document under “Generic Requirements on HTTP Usage” section. 4. Control Once the control point obtains the UPnP description of the device, it can send control queries to the device and invoke actions. The control protocol used for UPnP is the Simple Object Access Protocol (SOAP) over HTTP. The action invocation and action response message are written in XML syntax (Figure 13). The POST header field is the control URL defined in the device description controlURL element. The message sends out the action name and list of arguments that are required by the service. Similar to description retrieving, it is expect for the service to invoke action within 30 second and send back the action response (Figure 14) to the control point once the service receives the action request. Upon on the success of executing the action, the service may send arguments back to the control point, these arguments name and their values are listed in the in the response message. If an error occurs during the execution of action, an error message will send back to the control point documenting the error code and error descriptions. The error message format is shown in figure 15: For more information about the tag attributes and values, please refer to the UPnP Device Architecture document. 5. Eventing Each service defines elements to monitoring service states. The service can inform the control point(s) if there is a change of the state variables. This is known as Eventing. UPnP eventing is based on GENA and it is delivered over HTTP. Currently, the UPnP specification defines both unicast eventing and multicast eventing methods. The unicast eventing follows the subscriber-publisher model. Typically the subscriber is the control point while the publisher is the service. The multicast eventing introduces the concept of receiver to refer to the control points or devices that listen to the cast of the event. Unicast Eventing The GENA provides 3 HTTP methods for unicast eventing: *SUBSCRIBE *UNSUBSCRIBE *NOTIFY SUBSCRIBE To subscribe to a service eventing, the control point sends out a subscription request with the format shown in figure 16 to the event subscription URL, which is obtained from device description. Here the CALLBACK headerfield defines the address of the subscriber, so that the publisher know where the event message should send to. To ensure the connection between subscriber and publisher, the subscriber is recommended to periodically renew the subscription to a publisher. The renewal message has the following format defined in figure 17: Note that for subscription renewal message, the NT headerfield and the CALLBACK field are replaced by SID (i.e. Subscription ID). The SID is generated by the publisher to identify particular pair of publisher and subscriber. UNSUBSCRIBE When the control point wants to cancel a subscription, it uses the UNSUBSCRIBE method provided by GENA and the unsubscribe request message has the following format shown in figure 18: Event Message When the state variable changes within a service, the service sends out event message to the subscribers. The location of the subscriber is documented in the CALLBACK headerfields in the subscribe requests. The event message includes the name of the variable that has been changed and the value the variable has changed to. The event message adopts the following format summarized in figure 19: Multicast Eventing The event message can also be delivered through multicasting to 239.255.255.246:7900. The multicasting address is the same as SSDP in the discovery phase but it uses different port number. The format of multicast event message is defined in figure 20. 6. Presentation The UPnP architecture supports the browser based UI. In the phase of retrieving device description, if the device has a URL that locates to its control page, then the control point can load the UI in a browser and start the UPnP presentation. Example: UPnP enabled Alarm Clock Now let’s consider an arbitrary example. Imagine now there is a new alarm clock product that has built in WI-FI and UPnP enabled. The alarm clock can connect to the router (which is UPnP enabled) via Wireless LAN connection. On the other hand, I can connect my laptop to the same LAN and also enables the UPnP on my laptop. Through UPnP, the alarm clock can be remotely controlled by the laptop, assume that the alarm clock implement the required service. In this example, the relationship between physical device, logical device, service, actions, and event variables can be demonstrated by the following figure. As shown in figure 21, given that the device and services are available, the control point on the laptop can invoke action “set_clock_time” to the first service and change the “current_time” to the desired time. This is done by sending action request to the control URI of the service. For this example, the action name is “set_clock_time”, the argument name can be something like “time_value”, and the argument value can be some combination of numbers that represents the desired time, e.g. 1707 -> 17:07. Once the service receives the request, it execute the action within 30 second and send a response back to the laptop to indicate whether the action is successful or not (This can be achieved by sending specific argument value in the responds message). Figure 2 also shows that there are several state variables that the control point can listen to. In this case, the control point subscribe to the state variable “alarm_state”. Let’s define that “alarm_state” variable has two values 0 and 1, which corresponds to alarm is not ringing and alarm is ringing. When the alarm rings from silence, the “alarm_state” changes from state 0 to state 1. This change will be published to the control point and then the laptop will receive certain form of notification. The presentation of this UPnP alarm clock could be a built in user interface web page. An analogy to this is the router configure page, such as the page pointed by 192.168.1.1.When the connection is established, I can use my web browser to logon to the UI page and control the alarm clock. Link between some UPnP concepts and NM In TELE9752, we come across the five functional areas for managing OSI system, they are: *Faults *Configuration *Accounting *Performance *Security By comparing the UPnP architecture with the definition of these five function areas, the following discussion can be made. UPnP Fault management: UPnP protocols built on existing low level and high level protocol stacks and some protocol stacks provide the ability for fault management to certain degree. For example, for UPnP control and eventing, the request is delivered through TCP. TCP has certain error detection and correction ability. In the discovery phase of the UPnP, the search and advertise messages are delivered via UDP. UDP has higher possibility for errors and loss of data. Therefore, when the message is send through UDP, it is required to periodically repeat the messages so that it ensures that devices on the network can properly receive the message. UPnP Configuration management: The motivation of design the UPnP architecture is mainly focuses on the ease of configuration of the devices. As documented in this Wiki, in each phase of UPnP operation, the interactions between devices, services and control point are automatic and require zero-configurations. Security Management: UPnP architecture is designed to maximize the ease of device configurations within a network. However, this may make the UPnP extremely unsecure, which will be discussed in the next section. UPnP Security – Is UPnP really unsafe? The discussion about the security concern of the UPnP has never stopped. The security concern raise up again when HD Moore from Rapid7 Community published a white paper addressing the findings about UPnP potential security flaws. The focus of the concern is on the lack of authentication of the UPnP protocol. As documented in Moore’s research paper, from June 1 to November 17 in 2012, he performed active scanning over the entire IPv4 address WAN network. In over five month time, UPnP discovery requests were sent about once a week to every routable IPv4 address. The collected data shows that shows that 81 million of UPnP enabled routers have response to the UPnP discovery requests. Throughout this wiki, I have briefly talked about how UPnP configures and communicates the devices on the network through addressing, discovery, description, control, eventing and presentation. At each stage, the design of the UPnP does not require the devices or control points to authenticate their identity. The problem with this is simple: “Device will response to any discovery request received over the network, even the device has no idea who sends the request”. This may not be a big issue in a well-defined internal network. For example, internal home network for home automation. But if the UPnP device is connected to the External network, that is the WAN, then this becomes a huge security flaw. Because a hacker can simply send UPnP discovery request to an UPnP enabled router to learn the basic information about the device, and subsequently changes the configurations of the router without user noticing the change. As a consequence, it is recommended to disable UPnP functionality on the router. Conclusion UPnP protocol is designed to optimize the device configuration capability such that the device achieves zero configuration. However, along with the convenience of this protocol, there is great security concerns. References # EmbeddedInn, UPnP Device Architecture, URL: http://embeddedinn.wordpress.com/tutorials/upnp-device-architecture/ # Applied Informatics Universal Plug and Play, 2013, UPnP Overview, URL: http://www.appinf.com/docs/poco/00100-UPnPOverview.html # UPnP FORUM, 2014, UPnP Device Architecture 2.0, URL: http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v2.0.pdf # UPnP FOURM, 2014, What is UPnP? ''URL: http://upnp.org/about/what-is-upnp/ # ''Security Now! Transcript of Episode #389, URL: https://www.grc.com/sn/sn-389.pdf # RAPID7, 2013, ''Security Flaws in Universal Plug and Play - Unplug. Don’t Play. ''URL: https://community.rapid7.com/servlet/JiveServlet/download/2150-1-16596/SecurityFlawsUPnP.pdf